When an existing route's path is updated to a new value not previously observed,
the new route state is correctly activated, but the previous route is not
replaced in the `hostRules` internal active list. Instead, the updated route
state (with a different path but duplicate UID) is appended to the active list.
A `hostRules` active list with more than one route instance sharing a UID and
host is an invalid internal state. The net effect is some unintended confusing
behavior which manifests when updating the route's path, including:

  * Updating from path A->B->A preventing future transitions to B

  * Updating from path A->B->A->B leaves an orphaned claim on the host in the
namespace, preventing the recreation of the route with either of the previously
observed paths until the router is restarted (causing the internal state to be
rebuilt)

Routes updates which are affected by this bug will be rejected with a status
like:

    message: route foo already exposes foo-ns.os.example.com and is older
    reason: HostAlreadyClaimed

Where `foo` refers to itself. This indicates the route update was rejected due
to a claim made by the same route being updated.

To fix the problem, ensure that when a path change is detected on the same route
the prior existing state is removed from the index, eliminating the possibility
of keeping an orphaned claim. Then add the new route as usual, which handles
acceptance/rejection normally.